Current anti-virus (or the more general, “anti-malware”) software systems are fighting a battle with malicious-intent software (i.e. “malware”) that has previously been largely unwinnable. The current systems focus on inspecting and alerting upon known (or weakly deduced) methods that malware authors and developers are constantly tweaking. The capabilities of current anti-malware systems to dynamically change their inspection techniques (outside of simple signature updates) are limited once installed on a host computer system in the field. This limitation creates numerous false positives and false negatives. True run-time dynamic response to changing threats is not an advantage of current anti-malware software. These current anti-malware systems oftentimes function with only moderate success until they completely fail due to a disruptive technology that is introduced by the malware developers. Until this new disruptive technology is observed, reverse-engineered, and understood by the anti-malware developers, the anti-malware's triggers and subsequent counter-measures are bypassed.
Ultimately, anti-malware will continue to fail so long as it functions within the current paradigm. Two primary characteristics condemn anti-malware systems to failure. These characteristics are that it (1) operates in a known manner and (2) operates from within the same context as the malware. Anti-malware functions in a “known manner” because there are operating system “rules” that it must abide by in order to avoid interfering with healthy system operations, and in some cases, in order to be approved by the operating system's manufacturer. These rules do not have to be followed by malware and oftentimes, depending upon the malware's ultimate goal, are stretched to the functional limit. Anti-malware also operates from within the same context that the malware operates. The issue of context does not necessarily signal a horrible practice, it is arguable that this must occur at some level in the current paradigm. However, by combining that anti-malware toolsets operate in a largely known way, function with the same level of access and act upon the same objects and structures within the system, anti-malware has not been able to actively attack malware. This is because the anti-malware is trying to retain its integrity while attempting to discover malware characteristics.
A paradigm shift must take place in order to be able to detect and remove malware from a computer system. There must be a shift in the strategy of attacking malware from a different context by employing a dynamic system.
FIG. 10 is a simplified block diagram of a system 1000 including a target host computer system 1011 and an analysis host computer system 1012. In FIG. 10, the target host computer system 1011 includes a central processing unit (CPU) 1014, also known as a “processor.” Central processing unit 1014 coacts with a non-volatile storage device, or hard disk drive (HDD), 1016 and with volatile memory 1018, sometimes known as Random Access Memory (RAM) or “physical memory,” across the multiple logical and physical layers of the target host computer system 1011 in order to perform various processes, as known in the art. The processes may include those of an operating system, such as Microsoft Windows©, which are initially stored in HDD 1016, and loaded into RAM 1018 at startup or initialization. Other programs and processes stored on HDD 1016 may be initiated from time to time or at startup. These additional programs and their support files result in processes being loaded into RAM 1018. Central Processing Unit 1014 acts upon these programs' commands in order to facilitate interaction between the user (where applicable), desired target host computer system hardware (which includes the processor 1014, RAM 1018, HDD 1016, etc.), and the target host computer system operating system. The user may interact with target host computer system 1011 by way of a physical device connected to user interface 1023. The device attached to user interface 1023 may be a keyboard, mouse, voice command arrangement, or the like.
In addition to the processes associated with the operating system intentionally loaded into HDD 1016 of target host computer system 1011 of FIG. 10, and in addition to the various executable, ancillary, and data files, the volatile memory 1018 may contain one or more malware processes or paths of malicious code execution (such as injected or patched dynamic linked libraries (DLLs), functions, drivers, etc.). Various means by which malware can be introduced into computer systems are well-known, and include computer viruses, Trojan horses, rootkits, and the like. The modes of transmission may include any of the paths by which the target host computer system 1011 interacts with its environment, including network connections 1072 accessed by a network interface 1022, disk drives, and the like. However introduced, the malware processes and malicious code paths may become resident within volatile memory 1018 and be executed by the processor 1014. When resident only within RAM 1018, such malware can be countered by (a) “rebooting” the target host computer system 1011 to thereby halt power to the RAM 1018, which without power and under normal conditions will effectively clear the contents of RAM 1018 of any discernible execution paths, and (b) then re-loading the RAM 1018 with the benign or acceptable processes stored on HDD 1016.
Under some conditions, the malware processes may also become resident on HDD 1016 of target host computer system 1011. This by itself is not necessarily deleterious, as the malware may adversely affect the operation of the target host computer system 1011 only when it becomes resident in RAM 1018 where it can interact with the benign or acceptable processes. However, when the target host computer system 1011 is rebooted with malware resident on the HDD 1016, the malware is likely to be re-introduced into the RAM 1018. Under these conditions the malware can now persist on the target host computer system 1011 during periods when the RAM 1018 cannot maintain its state or the contents of its memory (e.g. when it loses power during events such a reboot or power cycle of the target host computer system 1011). In cases such as these, rebooting the target host computer system 1011 may not effectively deal with the malware infection. When malware is introduced into the volatile memory, it may become intermixed with or “infect” one or more of the benign, acceptable or, “good” processes.
Security programs, such as those provided by McAfee, Norton, Webroot, and others, are often used with computer systems to counter various types of malware, such as spyware and viruses. Such security programs are intended to monitor information introductions to the computer by many potential paths and to sequester information identified as malware, render it harmless, or at least to warn of the presence of malware.
It is well-known that the providers of security programs are at a disadvantage relative to the developers of malware. This disadvantage results from the difficulty of anticipating what new malware will arise, and the characteristics that might render the malware amenable to detection and countering. In effect, the malware protection available to the operator of a computer such as target host computer system 1011 of FIG. 10 “runs behind” the development of security countermeasures. Thus, there is always the possibility, if the target host computer system 1011 is made available for the introduction of information or data, that malware will be introduced. It is very desirable, considering the possibility that the security programs may be only partially effective, that the operator of the target host computer system 1011 of FIG. 10 allow only data from a trusted source to be introduced into the target host computer system 1011. While some anti-virus software might employ anomaly-based measures that the companies may claim will help detect “future” malware, these anomaly-based measures are simply rulesets which can be circumvented after careful study of the governing rules.
Notwithstanding the strict use of trusted information sources and faithful adherence to up-to-date security programs and practices, introduction of malware into computer systems is a fact of life. The introduction of malware can be highly deleterious, potentially allowing (a) the computer system to be taken over and used as part of a “botnet” (a network of malware components controlled from a command entity) for propagating malware or undesired communications (such as spam) to other computer systems, (b) revelation of sensitive personal data such as bank account numbers and passwords, and in the context of national security, loss or corruption of sensitive technical, strategic, or tactical information.
Malware, in order to perform its malevolent function when it infects a computer system, must be accessible by the CPU or similar processing unit located on the system—which typically means that it must be resident in RAM—at some point in its execution. Malware that takes up residence in RAM of a computer must have, by necessity, bypassed all of the identification steps mandated by the resident security program, or it must have been confirmed (even mistakenly) to run by the user of the computer system. The presence of malware may become obvious or be suspected due to untoward operation of the computer. The response is usually to run an anti-malware program in a “scan” mode in which all, or most, of the processes' address spaces in HDD and RAM are inspected for recognized patterns and/or behaviors. However, it may well be that the malware, having already escaped detection by the security program on its way to execution, may again escape detection during a scan or even ongoing examination by the security software. In some cases, malware, once executing, may attack the security software's ability to detect certain parts or capabilities of the malware. At this point there may be no remedy except to re-format the HDD 16 and re-load it with the acceptable or benign programs so as to be able to continue with its use.
Some malware may not make its presence known or suspected by refraining to adversely affect the appearance of normal operation. For example, a computer that has been acquired for a botnet may draw unwanted operator attention if the takeover gives overt indications, such as execution latency or catastrophic application or operating system failure. Thus, such malware attempts to hide its presence on the target host computer system. Since there is no overt indication of infection with malware, no countermeasures may be taken, and the infected target host computer system may continue to operate, apparently normally, except that it may “run” the benign programs and processes with increased, yet unnoticeable, latency, as some of its computing power is diverted to fulfilling its malicious tasks. Due to operating systems' behemoth size and inherent latency for non-malicious reasons, there often is little way for the operator to determine or notice any malware-attributable delay.
Increasing attention has lately been directed towards forensic examination of computer systems. United States patent application 2005/0204205, published Oct. 13, 2005 in the name of Ring et al. describes a method for finding malicious modules, processes, and system call patches in a computer system and restoring the system to an uncompromised state. In the method of the Ring publication, various analyses are performed, including system call table address correlation, module linked list address correlation, user space and kernel space process-view correlation, network port binding verification, and user and kernel space file-view correlation. These analyses are performed on each inspected host computer system and the comparisons are made with regards to a single host computer system. Ring's analyses state that “it senses anomalous operating system behavior when activity in the operating system deviates, that is fails to adhere to, a set of predetermined parameters or premises.” Not all malicious software affects systems in ways detectable by Ring's analyses.
Current methods of detection by anti-virus and anti-malware entities are reaching a point of diminishing return, because the depth and breadth of inspection can only be so extensive before noticeable overhead is produced, resulting in usability and functionality issues that become unbearable for users.
Numerous methods can be used to analyze the physical memory of a target host computer system. Before analyzing the contents of the physical memory however, it must be captured, or acquired. There are two primary modes or times at which physical memory capture can occur, namely live and off-line. “Live” memory capture occurs on the target host computer system and runs in the context of that operating system. “Off-line” physical memory capture occurs when the target host computer system's physical memory is not in operation and the physical memory has been stored in a binary file (such as in the case of a paused VMWare image or a computer in a state of “hibernation”). This binary file is then moved from the target host computer system (e.g., target host computer system 1011 of FIG. 10) and is analyzed on another host computer system, such as analysis host computer system 1012 of FIG. 10. Access to “live” physical memory can be performed through introduction of physical hardware or through software-based methods, such as by employing Application Programming Interfaces (APIs), well-known in the art. The copying and transfer of the “off-line” physical memory binary file can be performed in several ways. The target host computer system way is through an application that uses Application Programming Interfaces (APIs) to access and copy the physical memory to a binary file. This binary file is simply an on-disk copy of what is stored in physical memory. In the binary file format, we can now treat it as any typical system file and copy, move, read, or edit the data. A second way is to obtain physical memory binary files that have been created by virtual machine technologies or by the target operating system, such as hibernation files. Moving the data from the target machine can be performed in numerous ways as well. Using any method, the data can be transferred, as by path 1073 of FIG. 10, from the target host computer system 1011 to the analysis host computer system 1012. Path 1073 can involve using human interaction and removable media (such as CDs, floppies, etc.), a direct link (such as a null modem), or a network connection such as 1072 in order to transfer the data to the analysis host computer system 1012.
Recent strategies for removing malware from memory have typically focused on removing injected data structures from linked lists or repatching binary code that has been changed by the malware. While these methods are sound, the areas that they typically address do not cover the full spectrum of malware-targeted methods. As malware detection becomes increasingly proficient, malware's methods of hiding itself from discovery improve. This improvement typically means diving deeper into the lower levels of the operating system or taking advantage of increasing levels of indirection. As described earlier, it is increasingly difficult to perform these inspections by anti-virus/-malware software during run-time execution of the applications due to the increased overhead operations cost. Improved apparatus and methods are desired for cleansing malware from computer systems.